Field
Embodiments disclosed herein generally relate to Transport Layer Security (TLS) and Secure Sockets Layer (SSL), and more specifically, to updating server behavior during a TLS/SSL handshake protocol based on observed server resource metrics.
Description of the Related Art
Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are network security protocols that enable privacy and data integrity for network packets between a server and a client. A server performs an SSL handshake protocol to establish a secure session with a client. The handshake protocol manages cipher suite negotiation between the server and the client. That is, the protocol determines which combination of cryptographic algorithms the server and client will use during the session, server authentication, and session key exchange. During this process, the server performs a number of cryptographic algorithms. Generally, these algorithms consume significant computing resources from the server.
Servers that primarily process SSL workloads may occasionally receive a high volume of client requests, which in turn over-burdens server computing resources. This is particularly true for web-servers that primarily rely on RSA-based digital certificates during the SSL handshake. Although RSA is well known, as server traffic increases, CPU utilization of the server also increases, which may cause the server to drop requests or requests to time out. Further, with security guidelines requiring a higher security, the key lengths for current encryption methods using RSA are expected to increase. However, RSA key lengths increase in size exponentially, which results in a greater amount of CPU and network resources consumed by the server.
Alternatives to RSA-based encryption methods may reduce the burden on the server during the SSL handshake protocol. For example, elliptic curve cryptography (ECC)-based certificates are less computation-intense on the server. While RSA key lengths increase exponentially, ECC key lengths increase linearly. For example, 128-bit security requires a 3,072-bit RSA key. In contrast, the same may be accomplished with a 256-bit ECC key. Consequently, ECC-based certificates may reduce the burden of CPU and network utilization. However, one issue with such an approach is that support for ECC is much less prevalent than support for RSA. That is, many clients may prefer RSA-based encryption over ECC-based encryption. Indeed, some clients lack support for ECC altogether. In addition, ECC-based methods may be computationally expensive for client devices having lower hardware specifications (e.g., mobile devices). Therefore, relying on an ECC-based solution entirely may be impractical.